docs: Update release notes for versions 3.16.1, 3.16.2, and 3.16.3; a…#181
Merged
Conversation
dosubot
Bot
added
the
size:L
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
![ellipsis-dev[bot]](https://avatars.githubusercontent.com/in/64358?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed everything up to de49ad0 in 2 minutes and 31 seconds. Click for details.
- Reviewed
169lines of code in6files - Skipped
0files when reviewing. - Skipped posting
14draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. docs/update-notes/index.md:7
- Draft comment:
Ensure the release versions are listed in strict chronological order if that’s intended. The ordering here (3.16.3, 3.16.2, 3.16.1, then 3.16 Combined) may cause confusion. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The versions appear to be intentionally ordered with newest first, which is a common and logical way to display version history. The base version (3.16) having the same date as 3.16.3 makes sense as it could be a rollup/summary. The ordering follows the same pattern used throughout the entire document. The comment seems to be questioning an intentional and consistent ordering pattern. Could there be a UX reason why chronological order would be better? Some users might find it confusing to read newest-first. The newest-first ordering is a common convention for changelogs and release notes, as users are most often looking for recent changes. The pattern is consistent throughout the document. The comment should be deleted as it questions an intentional, consistent ordering pattern that follows common conventions for release notes.
2. docs/update-notes/v3.16.1.md:29
- Draft comment:
Consider adding a newline at the end of this file for consistency. - Reason this comment was not posted:
Confidence changes required:50%<= threshold50%None
3. docs/update-notes/v3.16.2.md:9
- Draft comment:
Consider adding a newline at the end of file for consistency with other Markdown files. - Reason this comment was not posted:
Confidence changes required:50%<= threshold50%None
4. docs/update-notes/v3.16.3.md:7
- Draft comment:
Consider adding a newline at the end of file for consistency. - Reason this comment was not posted:
Confidence changes required:50%<= threshold50%None
5. docs/update-notes/v3.16.md:55
- Draft comment:
Verify that the consolidated release notes fully capture all changes across sub-versions (3.16.1-3.16.3) to avoid information loss. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is asking the PR author to verify something, which is against the rules. It doesn't provide a specific code suggestion or point out a specific issue with the code.
6. sidebars.ts:182
- Draft comment:
Ensure the new update notes entries (3.16.3, 3.16.2, 3.16.1) in the sidebar are in the intended order and match the version ordering in the docs. - Reason this comment was not posted:
Comment looked like it was already resolved.
7. docs/update-notes/index.md:7
- Draft comment:
Review the ordering and date consistency for version 3.16 entries. The combined release note [3.16] (2025-05-08) is listed after sub-versions 3.16.3, 3.16.2, 3.16.1. Confirm if this ordering is intentional. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%The comment is asking the author to confirm if the ordering of version entries is intentional. This falls under the rule of not asking the author to confirm their intention or to double-check things. Therefore, this comment should be removed.
8. docs/update-notes/v3.16.1.md:29
- Draft comment:
Add a newline at the end of the file for POSIX compliance. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While having a trailing newline is a common convention and good practice, this seems like something that should be handled by EditorConfig, Prettier, or similar tooling rather than manual code review comments. The comment is technically correct but not particularly valuable as a manual review comment. It's the kind of thing that should be automated. The comment is technically correct and follows a widely accepted standard. Not having a trailing newline could cause issues with some tools. While valid, this is exactly the kind of formatting issue that should be handled by automated tooling rather than taking up reviewer and developer time with manual comments. Delete the comment. This kind of formatting issue should be handled by automated tooling like Prettier or EditorConfig rather than manual review comments.
9. docs/update-notes/v3.16.2.md:9
- Draft comment:
Add a newline at the end of the file for POSIX compliance. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative and does not provide a specific code suggestion or highlight a potential issue. It does not align with the rules provided, which discourage purely informative comments.
10. docs/update-notes/v3.16.3.md:7
- Draft comment:
Add a newline at the end of the file for POSIX compliance. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct, this kind of formatting issue should be handled automatically by tools like ESLint/Prettier which are required by our standards. The comment is about a trivial formatting issue that should be automated rather than manually reviewed. Our rules specifically state to not comment on things that should be caught by automated tools. The trailing newline is a valid POSIX requirement and could cause issues in some contexts. Maybe this is important enough to flag manually? No - our development standards explicitly require ESLint/Prettier setup with pre-commit hooks. This is exactly the kind of thing that should be caught automatically rather than in code review. Delete this comment as it addresses a formatting issue that should be handled by required automated tools rather than manual review.
11. docs/update-notes/v3.16.md:89
- Draft comment:
Ensure the file ends with a newline for consistency. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% While having a trailing newline is a common convention, this kind of formatting issue should be handled automatically by ESLint/Prettier rather than through manual code review comments. Our development standards specifically mention that ESLint and Prettier should be set up to enforce code style rules automatically. Making manual comments about formatting is not the best use of code review. The comment is technically correct - files should end with newlines. And it's a simple, clear suggestion. However, this is exactly the kind of thing that should be handled by automated tooling rather than manual review. Making comments about formatting issues creates unnecessary noise in code reviews. This comment should be deleted since formatting issues like trailing newlines should be handled by ESLint/Prettier automation rather than manual review comments.
12. sidebars.ts:184
- Draft comment:
The sidebar update for release notes looks correct, but verify that the ordering (with '3.16 Combined' appearing before individual sub-releases) matches the intended display order compared to the index.md listing. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is asking the PR author to verify the ordering of the sidebar update, which is against the rules as it asks for confirmation of intention. It does not provide a specific suggestion or point out a clear issue.
13. docs/update-notes/index.md:60
- Draft comment:
Typographical inconsistency: The link for version [3.11.0] uses '/update-notes/v3.11' instead of '/update-notes/v3.11.0'. For consistency and clarity, please update the URL to include the trailing '.0'. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
14. docs/update-notes/v3.16.2.md:9
- Draft comment:
The file is missing a newline at the end. Please add a newline to ensure consistency and avoid potential issues in some environments. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While having a newline at the end of files is a common convention, this kind of formatting issue should be handled by automated tools like ESLint/Prettier rather than manual review comments. Our rules specifically state that we should have these tools set up to handle code style automatically. This is exactly the kind of minor formatting issue that should be caught by tooling. The missing newline could cause issues with some tools or when concatenating files. It's a real concern that has practical implications. While valid, this is precisely the kind of issue that should be caught and fixed automatically by our required tooling setup, not through manual review comments. Delete the comment. This formatting issue should be handled by ESLint/Prettier automation rather than manual review.
Workflow ID: wflow_VX2ahlD4aCX7MaQm
You can customize 
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…dd to sidebars
Important
Update release notes for versions 3.16.1, 3.16.2, and 3.16.3, and add them to the sidebar.
3.16.1,3.16.2, and3.16.3indocs/update-notes/.index.mdto include links to the new release notes.v3.16.mdto reflect changes up to version3.16.3.3.16.1,3.16.2, and3.16.3insidebars.tsunder the3.16category.This description was created by
for de49ad0. You can customize this summary. It will automatically update as commits are pushed.